Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-068

Text File | 1995-12-31 | 89KB | 2,218 lines

Received-Date: Thu, 17 Nov 1994 15:39:23 +0100
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-068
To: [e-mail]
Date: Thu, 17 Nov 1994 15:39:10 +0100 (MET)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 74

C.S.M.P. Digest             Thu, 17 Nov 94       Volume 3 : Issue 68

Today's Topics:

        How do you get the bit depths the main device supports?
        MIDI programming
        Memory management in the Real World, part 2
        Q: Sound Input Device
        QC FAQ
        ResEdit 2.1.3, is it good this time?
        Shareware, VISA Merchant Accounts, and YOU!
        Smalltalk implementations for Mac - update needed
        What is MIDI Manager etc (reply)



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Matt Mora)
Subject: How do you get the bit depths the main device supports?
Date: 31 Oct 1994 11:56:33 -0800
Organization: SRI International, Menlo Park, CA


At Init time I would Like to get the number of bit depths the main device
can support and make a small Gworld for each of theses bit depths. Is there a
call that can tell me what the main device can support?


Thanks,

Xavier






--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Chris Burns)
Date: Tue, 01 Nov 1994 21:44:39 +1200
Organization: AucklandUniversity:ComputerScience:HMU

In article <393i5h$[e-mail]>, [e-mail] (Matt Mora) wrote:

> At Init time I would Like to get the number of bit depths the main device
> can support and make a small Gworld for each of theses bit depths. Is there a
> call that can tell me what the main device can support?

Yep, it's a status call to the video (screen) driver.

Look in <Video.h>. You use the cscGetMode status call. I'll have to get
back to you with some code (Pascal:), tho' "Designing Cards & Drivers" has
it all well documented.

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]                         Async, therefore I am.
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Eric Hegstrom)
Date: 1 Nov 1994 23:14:24 GMT
Organization: 3DO Company

In article <[e-mail]>
[e-mail] (Chris Burns) writes:

> > At Init time I would Like to get the number of bit depths the main device
> > can support and make a small Gworld for each of theses bit depths. Is there a
> > call that can tell me what the main device can support?
>
> Yep, it's a status call to the video (screen) driver.
>
> Look in <Video.h>. You use the cscGetMode status call. I'll have to get

Or you can do it by stepping through HasDepth with all the possible bit
depths. (Dot overuse the HasDepth function because it has a small
memory leak -- $2A bytes per call if I remember correctly).

for (bd=1; bd <= someBigNumber; bd *= 2 )
    HasDepth( ..., bd, ...);

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-
This in no way represents the opinion of my employer
-- or anyone at all for that matter.

Eric Hegstrom     [e-mail]    -or-   [e-mail]

A very bright programmer -- I'm wearing flourescent underware.

+++++++++++++++++++++++++++

>From [e-mail] (Alex Rosen)
Date: 2 Nov 1994 21:35:25 GMT
Organization: Massachusetts Institute of Technology

Use the HasDepth call, available with System Software 6.0.5 or
thereabouts.  Check out Tech Note DV10.  (You can find it on
ftp.apple.com).

--Alex


---------------------------

>From [e-mail] (Bengt M}nsson)
Subject: MIDI programming
Date: Tue, 1 Nov 1994 21:31:26 GMT
Organization: CelsiusTech AB

Hi out there!
Being both a hobby musician and a hobby programmer I would like to get hold
of some information:
a) The specification for MIDI files
b) How to write applications for the Apple MIDI Manager (or do I have to go
   through the troubles getting it from Apple?)
c) How to write my own MIDI driver (if at all possible in Pascal)
Are these issues covered in any document available via ftp?

Bengt M}nsson

+++++++++++++++++++++++++++

>From [e-mail] (Jeff Beeghly)
Date: 1 Nov 1994 23:45:04 GMT
Organization: University of Washington

>a) The specification for MIDI files

I can't help you out too much on this one, but I KNOW I have seen ftp
sites on the net which carry a description & breakdown of standard MIDI
file formats... I just don't know where...


>b) How to write applications for the Apple MIDI Manager (or do I have to go
>   through the troubles getting it from Apple?)

It's probably a best bet to purchase the MIDI developer guide from
Apple.  At $35, it's not TOO bad.  There is one example floating around
that might help you out... it's called QwertyTunes and is from someone at
Apple Developer Tech Support.  ftp to ftp.apple.com... it should be
somewhere there.  Other than that, I haven't seen any other examples.


>c) How to write my own MIDI driver (if at all possible in Pascal)
>Are these issues covered in any document available via ftp?


Ummm..... I wouldn't do that....  Are you meaning you want to write
something that will replase the Apple MIDI Manager?  DON'T!!!
Use the Apple MIDI Manager.  If it's not what you're looking for, check
out FREE MIDI (by Opcode, I think).  Unless you are planning on writing a
MIDI driver for your own use, and never plan on releasing any apps that
use your driver, it will be a waste of your time.


Jeff


---------------------------

>From [e-mail] (Jeff Beeghly)
Subject: Memory management in the Real World, part 2
Date: 18 Oct 1994 16:46:56 GMT
Organization: University of Washington


I was speaking with one of my co-workers today about having to deal with
handles, MoreMasters, etc... on the Mac.  I come from an ANSI-C
background and am more comfortable with pointers.  I feel somewhat
comfortable with handles, but there are lots of "Brick Walls" which I
am encountering - like linked lists, and the fact that you need to
pre-determine the maximum number of handles the app WILL EVER need at
the beginning of the program.  He told me that Windows used to
be like the Mac (he's a Windows programmer) in terms of memory management:
everything needed to be done with handles (because the memory was being moved
around) up until Windows 3.1.  In 3.1, Windows could be run in what's
known as Protected Memory Mode.

In Protected Memory Mode, programmers didn't have to worry about handles
- they could just use pointers.  Yes, memory is still being moved around
to compact space, but in PMM, the HARDWARE is handling the memory management.

Programmers can just use pointers.  The pointer points to a location, and
that location is being handled be the hardware (if I understand my friend
correctly).  If the memory needs to be moved around, the hardware keeps track
of everything and the programmer doesn't need to worry about it.

My friend (the Windows programmer) said that I should see if the Macs
have anything like this.  Maybe not the 68000 macs but maybe the 68030 &
68040.  He said that the mac chips are really advanced and he would be
surprised if they didn't have it (for a Windows programmer, he was very
supportive of the Mac).

Now, I don't want to start any Windows vs Mac debates, I was just
wondering if there is a Mac equivalent of Protected Memory Mode?



+++++++++++++++++++++++++++

>From [e-mail] (MARK H. LINTON)
Date: 18 Oct 94 17:18:10 EST
Organization: HRB Systems, Inc.

In article <381538$[e-mail]>, Eric Kidd <[e-mail]> writes:
> In article <380u60$[e-mail]> Jeff Beeghly,
> [e-mail] writes:
>>I was speaking with one of my co-workers today about having to deal with
>>handles, MoreMasters, etc... on the Mac.  I come from an ANSI-C
>>background and am more comfortable with pointers.  I feel somewhat
>>comfortable with handles, but there are lots of "Brick Walls" which I
>>am encountering - like linked lists, and the fact that you need to
>>pre-determine the maximum number of handles the app WILL EVER need at
>>the beginning of the program.
>
> [interesting idea re: Windows snipped]
>
> You don't need to worry about filling your master pointer blocks. New ones
> will be automatically allocated by the Memory Manager if you declare more
> handles than you had expected when you were making your MoreMasters calls.
>
> There is a catch, however: these blocks are non-relocatable and will
> fragment your heap if they are not allocated at one end or the other. To
> avoid this, Mac programs try to guess a "normal maximum # of handles" at
> initialization time. This is what you are dealing with, not an absolute
> limit.
>

        Eric (and Jeff, hello again ;^),

        Maybe the mystery surrounding the Handle in the Macintosh world
        is really the puzzler. Easy way around it? Use NewPtr instead of
        NewHandle. If all you are trying to do is make a linked list,
        there is no need to muddy the water with a Handle based
        solution. Now if you are using a ToolBox call (that was designed
        to run on a machine that had 128k of RAM) then you may have to
        use a handle, but you are not required to use them in your own
        data types.

        As far as nifty ways to control memory, you really have to get
        Inside Macintosh: Memory. What are you missing if you don't?

        o Multiple heaps/heap zones
        o Temporary Memory - allows you to (temporarily) access more
          memory than your program is allocated
        o More complete functions for assessing memory conditions:
          - FreeMem/FreeMemSys
          - MaxBlock/MaxBlockSys
          - PurgeSpace
          - StackSpace
        o More complese functions for freeing memory
          - CompactMem/CompactMemSys - compacts (system) heap
          - PurgeMem/PurgeMemSys - purges (system) heap
          - MaxMem/MaxMemSys - compacts and purges (system) heap
        o Virtual Memory

        Jeff said he didn't want to start a Mac/Windows flame war, so I
        won't say what I think of extended memory.

--
Hope this helps.

Mark H. Linton
____________________________________________________________________
mark \'m‰rk\ n [ME, fr. OE mearc boundary, march, sign; akin to OHG
marha boundary, L margo] 1 a : a conspicuous object serving as a guide
for travelers 2 : A standard or criterion of quality 3 : An object or
point that serves as a guide --idiom. mark time. 1 : To make little or
no progress

+++++++++++++++++++++++++++

>From [e-mail] (Kevin Vail)
Date: Tue, 18 Oct 1994 18:10:19 -0400
Organization: Vailhalla

In article <380u60$[e-mail]>, [e-mail]
(Jeff Beeghly) wrote:

>I was speaking with one of my co-workers today about having to deal with
>handles, MoreMasters, etc... on the Mac.  I come from an ANSI-C
>background and am more comfortable with pointers.  I feel somewhat
>comfortable with handles, but there are lots of "Brick Walls" which I
>am encountering - like linked lists, and the fact that you need to
>pre-determine the maximum number of handles the app WILL EVER need at
>the beginning of the program.  He told me that Windows used to
>be like the Mac (he's a Windows programmer) in terms of memory management:
>everything needed to be done with handles (because the memory was being moved
>around) up until Windows 3.1.  In 3.1, Windows could be run in what's
>known as Protected Memory Mode.
>
>In Protected Memory Mode, programmers didn't have to worry about handles
>- they could just use pointers.  Yes, memory is still being moved around
>to compact space, but in PMM, the HARDWARE is handling the memory management.

That's because the underlying hardware (80386 or higher) uses two items to
locate any piece of data: a SELECTOR (or "segment") and an OFFSET into the
segment.  The selector is two bytes, the offset can be two or four.  This
has always been how memory is accessed on the 80*86 chips, but in
non-protected mode the selector part is called the "segment" and indicates
a physical memory segment address (a segment can begin at any
divisible-by-16 memory address).  You take the segment and shift it four
bits to the left and add in the offset.  This gives you a 20-bit (up to 1
megabyte) address.

In protected mode, however, the selector bears no relation to the physical
memory address except that the hardware uses it as an index into a table
of physical addresses.  It takes the beginning of the segment address and
adds the offset to that to give the actual memory address.  In protected
mode, there is a 4 gigabyte (32-bit) address space.  Since the actual
physical address is only stored in the table that the selector indexes
into, the operating system (i.e., Windows) can move the physical location
around; the program still uses the same selector to access it.

This is not possible on the Mac because the Motorola 680*0 chips use a
linear address space with none of this segment/selector garbage.  Windows
has always used a selector-plus-offset memory model (they refer to the
segment part as a "handle"); it used to be that you had to make a Windows
call to find the *real* memory address, but now it's the same, because of
the way selectors work in protected mode.  It has a few advantages in
special-purpose cases like Windows memory allocation, but in general it's
*much* easier to define and use a linear address space.

[snip]

>Now, I don't want to start any Windows vs Mac debates, I was just
>wondering if there is a Mac equivalent of Protected Memory Mode?

The short answer is No, not in the sense you're talking about.  (The MMU
in the 68030 and 68040 is capable of setting up protected memory regions,
but this isn't used in the MacOS.)

However, here's a thought, and maybe this is what Apple is doing in
Copland-- wouldn't it be possible to set up the memory so that each
program had its own address space, with the system heap somehow shared?  I
don't know what you could do with low-memory globals (perhaps set them up
so each program had its own copy, or make them read-only so that writes
cause a trap so that changes to the low-memory stuff could be tracked by
the OS) and I know there's other stuff, but this would provide memory
protection between tasks and give every program a heap the size of the
address space; no more trying to guess partition sizes.  You'd still have
to dereference handles, though...
--
Kevin Michael Vail  | "This is so cool I have to go to the bathroom!"
[e-mail] |                   -- Calvin

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Wed, 19 Oct 1994 08:31:31 +0100
Organization: Royal Institute of Something or other

In article <380u60$[e-mail]>,
[e-mail] (Jeff Beeghly) wrote:

>comfortable with handles, but there are lots of "Brick Walls" which I
>am encountering - like linked lists, and the fact that you need to

Linked lists with handles is just as easy as with pointers.
Just remember to store the HANDLE, not the de-referenced pointer.

>pre-determine the maximum number of handles the app WILL EVER need at
>the beginning of the program.  He told me that Windows used to

Uh? You should make a good guess, if you're really interested
in efficiency. You can just leave it be, in which case the
system will allocate onrelocatable master pointer blocks in
your heap when needed - depending on how you code, these
allocations may or may not cause memory fragmentation. Mostly
they don't.

>In Protected Memory Mode, programmers didn't have to worry about handles
>- they could just use pointers.  Yes, memory is still being moved around
>to compact space, but in PMM, the HARDWARE is handling the memory management.

You can use pointers to your hearts content in the Mac as well.
Yes; there may be fragmentation, but that's the case for
Windows as well (it just masks the fact) Indeed, fragmenting VM
tables is in many cases just as bad as fragmenting "real" memory.

Windows handles are NOT the same as Mac handles; Windows memory
isn't like Mac memory at all because of their painful segmented
architecture. Just go ahead and use malloc()! For as much
memory as you want! And don't worry about pointer arithmetics;
unlike Windows 3.1, it'll always work.

Cheers,

                / h+



--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

"I like to do very very late binding. åJust in timeπ binding."
    ã Dave Feldt


+++++++++++++++++++++++++++

>From [e-mail] (Bretton Wade)
Date: Wed, 19 Oct 1994 08:35:10 -0400
Organization: Cornell Program of Computer Graphics

In article <[e-mail]>, [e-mail] (Jon
W{tte) wrote:

> Windows handles are NOT the same as Mac handles; Windows memory
> isn't like Mac memory at all because of their painful segmented
> architecture. Just go ahead and use malloc()! For as much
> memory as you want! And don't worry about pointer arithmetics;
> unlike Windows 3.1, it'll always work.

It's been a while since I was coding in MS Windows. Do they still have
that silly global limit on the number of handles? It was ridiculously low,
like 64 or something...

______________________________________________________________
   Bretton Wade ([e-mail])
   http://www.graphics.cornell.edu/~bwade/
______________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Nicolas Tamburri)
Date: 19 Oct 1994 14:44:59 GMT
Organization: Stratus Computer, Inc.

In article <[e-mail]>, [e-mail] (Kevin Vail) writes:
>
> However, here's a thought, and maybe this is what Apple is doing in
> Copland-- wouldn't it be possible to set up the memory so that each
> program had its own address space, with the system heap somehow shared?  I
> don't know what you could do with low-memory globals (perhaps set them up
> so each program had its own copy, or make them read-only so that writes
> cause a trap so that changes to the low-memory stuff could be tracked by
> the OS) and I know there's other stuff, but this would provide memory
> protection between tasks and give every program a heap the size of the
> address space; no more trying to guess partition sizes.

I hope this is what they are doing, since this was old technology 20
years ago.

I assume that the reason it has not been done yet is because of low
memory globals and compatibility with older programs.  The way other
vendors have solved this problem (and related memory sharing problems,)
is 4 fold:

1. You publish a decree that says "Henceforth storing directly into
   low-memory globals is considered to be a bad programming practice,
   and we are providing you with this/these OS calls for modifying
   those globals."

2. If you need to set up shared memory between processes, you must use
   these OS calls, i.e. don't assume that the same numeric address
   actually refers to the same physical memory location.

3. Each process on the system gets its own address space, as you state.
   The low-memory addresses are set up so that reads and writes to them
   actually trap to the OS, which takes apart the instruction and stuffs
   the global data into the process space, (or vice-versa.)  For most
   globals, this is sufficient, for some, a global can only be used by
   one process at a time, and if pre-emptive multi-processing is used,
   the calling process may actually block until valid data becomes
   available.

   This extra processing is much less efficient than accessing globals
   directly, and thus becomes the incentive to not use them.  But, it
   does provide compatability for older programs that may never be
   updated, even though they may run slower.

4. Spend a bunch of time shaking out the incompatabilities, since what
   I've described is greatly simplified.  (On the other hand, it's not
   like I can run every program I've ever bought on my Q650, so maybe
   they won't worry too much about this last part.)

Anxiously awaiting Copeland and Gershwin...

                            /nt



+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 19 Oct 1994 18:03:45 GMT
Organization: Apple Computer

MARK H. LINTON, [e-mail] writes:
>         Maybe the mystery surrounding the Handle in the Macintosh world
>         is really the puzzler. Easy way around it? Use NewPtr instead of
>         NewHandle.

Not if you're worried about performance; NewPtr is really slow. A better idea
is to use the malloc/free routines in your development system's ANSI library.
Generally (at least in THINK and CW) these allocate large blocks via NewPtr
and then sub-allocate them, which is a lot more efficient than using the Mac
memory manager straight. The drawback is that these blocks are not disposed
back to the Mac heap, so you have to make sure that malloc doesn't eat up too
much of your memory (you need enough free to keep the Toolbox happy.)

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From Lloyd Sargent <[e-mail]>
Date: 21 Oct 1994 15:04:39 GMT
Organization: Canna Software Development

Re: Memory management in the Real World, part 2

Don't get me started on that "feature" of Windoze. Yes, it is true,
Virginia, they do move pointers around without handles.  But it is
at a cost -- you have to follow some rules about how your data is
formated (i.e. you can't have words on 64K boundaries and a host of
others that I soon as well forget).  It is better?  Depends on your
point of view.  When coding, handles don't slow me down. They are
just another data structure.  True, it slows the system down moving
the handles (and their data) around, but it is just as ugly on the
Windoze side.

I have to admit, that one feature of Windoze saved my butt (we had
to build a 2 mb structure in order to get the speed required for
a customer - if we had used Windoze handles it would have meant re-
writing large chunks of s/w in a couple of days.

It really boils down to methodology. And that is about a touchy
subject as religion and politics!

Cheerio,

Lloyd

- --------------------------------------------------------------------
Lloyd Sargent              | "{The mice} are merely the protrusions into
Canna Software Development | our dimension of vast hyper-intelligent pan-
Del Valle, Texas           | dimensional beings, thw whole business with
Infobahn: [e-mail]    | cheese and squeaking is just a front"
AppleLink: CANNA.SW.DEV    |            Hitchhikers Guide To The Galaxy
Voice: 512.243.0283        | "nam et ipsa scientia potestas est"
       512.243.3355        | {for knowledge too is itself power}
 "Been there, done that."  |            Francis Bacon

+++++++++++++++++++++++++++

>From Glenn L. Austin <[e-mail]>
Date: Fri, 21 Oct 1994 18:39:15 GMT
Organization: Eugene FreeNet

In article <[e-mail]> Jens Alfke,
[e-mail] writes:
>Not if you're worried about performance; NewPtr is really slow. A better
idea
>is to use the malloc/free routines in your development system's ANSI
library.
>Generally (at least in THINK and CW) these allocate large blocks via
NewPtr
>and then sub-allocate them, which is a lot more efficient than using the
Mac
>memory manager straight. The drawback is that these blocks are not
disposed
>back to the Mac heap, so you have to make sure that malloc doesn't eat
up too
>much of your memory (you need enough free to keep the Toolbox happy.)

DON'T USE malloc/free!!!  Although they do sub-allocate, they still call
NewPtr, and if you think you'll get better performance calling something
that calls NewPtr, you need to check your logic circuits.

Use NewPtr and DisposPtr, or better yet, design your own
malloc/realloc/free using locked, dereferenced handles.  This way you can
control your memory usage and still have the resizable objects that true
pointers don't provide (there is a SetPtrSize, but that's a crash waiting
to happen, since it doesn't work exactly like realloc but attempts to
resize the memory block in place, while SetHandleSize is allowed to move
the unlocked block of memory to satisfy the request).

The only time to use true malloc/free is under Windows, since that
brain-dead operating system only allows for 8192 total global handles,
and the only way to handle large amounts of data is to use the dev.
environment's large model (or huge model) and let it allocate and
suballocate memory for you.
//
// Glenn L. Austin
// Computer Wizard and Racing Car Driver
// Internet:  [e-mail]
//

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Sun, 23 Oct 1994 16:51:17 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Christian E. Hopps) writes:
>An MMU is not setup to handle application based resizing mostly.

>I'me not sure if you've had experiance with MMU's before or not.  However
>MMU's do not map just any logical address to just any physical one (in
>most cases.)  The 680x0 MMU's and the PPC MMU's map pages (4k or 8k mostly).

     Interestingly, Intel 386 machines and up have MMUs that are designed to
manage lots of segments, with sizes ranging from a few bytes to many
megabytes.  The bounds of the segment are expressed in bytes, not pages,
until the segment gets really big, and then it has to be rounded up to the
next chunk (512 bytes?).

     Because DOS/Windows doesn't fully use these capabilities, they aren't
well known.  But the CPU architecture is almost ideal for a system with lots
of little protected objects.  The PenPoint prototype used it quite
successfully, before AT&T bought it and made them switch to another CPU.

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Devon Hubbard)
Date: Tue, 18 Oct 1994 21:21:15 GMT
Organization: Taligent, Inc.

In article <380u60$[e-mail]>, [e-mail]
(Jeff Beeghly) wrote:

>Now, I don't want to start any Windows vs Mac debates, I was just
>wondering if there is a Mac equivalent of Protected Memory Mode?

Not currently, no.  :-]

dEVoN

- -----------------------------------------------------------------------
Devon Hubbard                                               Silicon Pilot
[e-mail]                                  Taligent, Inc

+++++++++++++++++++++++++++

>From [e-mail] (Larry Rosenstein)
Date: Wed, 19 Oct 1994 01:20:02 GMT
Organization: Taligent, Inc.

In article <1994Oct18.171810.22120@hrbicf>, [e-mail] (MARK H.
LINTON) wrote:

>         is really the puzzler. Easy way around it? Use NewPtr instead of
>         NewHandle. If all you are trying to do is make a linked list,

NewPtr is very slow because it tries to place the pointer as low in the
heap as possible.  You may be better doing NewHandle and immediatly
locking the handle.

--
Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Rick Holzgrafe)
Date: Wed, 19 Oct 1994 03:21:41 GMT
Organization: Semicolon Software

In article <380u60$[e-mail]>, [e-mail]
(Jeff Beeghly) wrote:

> the fact that you need to
> pre-determine the maximum number of handles the app WILL EVER need at
> the beginning of the program.

Well, you don't *need* to. The Mac will allocate more master pointer
blocks for you as and when needed. But you do *want* to, because master
pointer blocks are themselves locked. The system will spend time trying to
move unlocked handles around in order to place the master pointer block
near one end of your heap, to avoid fragmentation; and if it can't manage
it, then you get fragmentation anyway.

-- Rick Holzgrafe, a member of the Taligentsia
   [e-mail]
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (EDevinney)
Date: 24 Oct 1994 16:11:04 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (John Nagle)
writes:
>>>
 Interestingly, Intel 386 machines and up have MMUs that are designed to
manage lots of segments, with sizes ranging from a few bytes to many
megabytes.  The bounds of the segment are expressed in bytes, not pages,
until the segment gets really big, and then it has to be rounded up to the
next chunk (512 bytes?).

     Because DOS/Windows doesn't fully use these capabilities, they aren't
well known.  But the CPU architecture is almost ideal for a system with
lots
of little protected objects.  The PenPoint prototype used it quite
successfully, before AT&T bought it and made them switch to another CPU.
<<<

The PenPoint memory manager used 4k pages throughout.  One could create
new heaps for variable-sized data, and that was nice, but those also used
4k pages - you wouldn't use a heap like a handle if you gave any thought
about overhead.  It would be nice to use the MMU to get a protected,
never-fragmenting soup of variable-sized objects, but PenPoint didn't have
it.

Regardless, PenPoint did show me that while VM is nice, it is by no means
the panacea that handle-opponents often make it out to be.  Real RAM does
eventually run out, and it runs out quick on small (ie commonplace)
machines.  Performance takes a big hit when thrashing, and users find that
unacceptable, and it can kill battery life on mobile machines.  Like
handles, VM should be used with care and a full understanding of the costs
involved.

regards -

ed devinney (GO & EO alumnus)



+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 24 Oct 1994 19:30:56 -0800
Organization: Novell, Inc., Walnut Creek Macintosh Site

In article <[e-mail]>,
[e-mail] (Bretton Wade) wrote:

>> It's been a while since I was coding in MS Windows. Do they still have
> that silly global limit on the number of handles? It was ridiculously low,
> like 64 or something...

8192. Yes, ridiculously low, if you use those blocks for general managment
and don't break them up internally to your program. I believe their 32-bit
environments lift the restriction, though.

--
 Views expressed here do not necessarily reflect the views of Novell.

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 24 Oct 1994 19:34:53 -0800
Organization: Novell, Inc., Walnut Creek Macintosh Site

In article <[e-mail]>, Glenn L. Austin <[e-mail]> wrote:

> DON'T USE malloc/free!!!  Although they do sub-allocate, they still call
> NewPtr, and if you think you'll get better performance calling something
> that calls NewPtr, you need to check your logic circuits.

Do some benchmarking, Glenn. They really are faster. They call NewPtr only
for blocks above a certain size and when a block which has been
sub-allocated fills up.

--
 Views expressed here do not necessarily reflect the views of Novell.

+++++++++++++++++++++++++++

>From [e-mail] (Tracy M Nelson)
Date: 25 Oct 1994 17:04:19 GMT
Organization: Securicor Telesciences Inc

John Nagle ([e-mail]) wrote:
:      Interestingly, Intel 386 machines and up have MMUs that are designed to
: manage lots of segments, with sizes ranging from a few bytes to many

Not surprising, since they copied many of the design elements of the iAPX432
processor, which relied on the concept of "capabilities" (a sort of an
address + access permission structure, which maps nicely into a two-register
data access scheme) to manage their objects.  I don't know anything about the
specifics of the '386 MMU, but it's possible that, given a proper
object-oriented OS and development environment, the x86 architecture could be
handy after all...

--
Tracy Nelson ([e-mail])
// WARNING: May contain code which is too intense for young programmers...

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Barry)
Date: Thu, 27 Oct 1994 08:33:20 GMT
Organization: OzEmail Pty Ltd Sydney Australia

Tracy M Nelson ([e-mail]) wrote:
: John Nagle ([e-mail]) wrote:
: : Interestingly, Intel 386 machines and up have MMUs that are designed to
: : manage lots of segments, with sizes ranging from a few bytes to many

: Not surprising, since they copied many of the design elements of the
: iAPX432 processor, which relied on the concept of "capabilities"
: (a sort of an address + access permission structure, which maps
: nicely into a two-register data access scheme) to manage their
: objects.  I don't know anything about the
: specifics of the '386 MMU, but it's possible that, given a proper
: object-oriented OS and development environment, the x86
: architecture could be handy after all...

Hmmm...the main problem with the 386 MMU (at least as far as selectors
go), is that there are only 8192 selectors available in each of the local
and global descriptor tables. Unfortunately, this would mean a maximum of
8192 objects per process (or in the case of Windows, 8192 handles in use
across the entire system).

Just as some further information, 386 handles have a granularity of 16
bytes, unless you want to address memory beyond 16Mb, at which point the
granularity goes up to 4k.

Also note that Microsoft is ditching the use of selectors as handles in
Chicago and NT, where they're using a flat address space.

Just a bit of input...personally I don't think the 386 architecture
can be useful.
Andrew

+++++++++++++++++++++++++++

>From [e-mail] (Philip Machanick)
Date: 28 Oct 1994 07:35:59 GMT
Organization: Computer Science Dept, U of Witwatersrand

In article <[e-mail]>, [e-mail] (Stephen M.
Webb) wrote:
> Virtual memory became possible only with the 68020, which was not in

Wasn't it the 68010 that added VM support? Some managed to find complex
hardware workarounds, like  second processor to handle page faults.

> production at the time the Mac was released.  Handles were required to
> support a pseudo-virtual memory scheme under which regions of memory
> could be relocated during a system call if necessary, and without
> notice, at run time.  Such a scheme does not require restartable instructions.

I don't think this is sufficient reason to introduce handles. Other
systems had things like overlays (clumsy but easier to program). I think
the real reason for overlays was system calls and user program were
allocating sometimes short-lived data (e.g. for menus) in the same small
heap. With so little RAM to play with a conventional memory manager would
have had problems coping. Things like puregeable resources help, but could
work without handles if there is enough free RAM to run a conventional
memory manager (with free list, coalescing adjacent blocks etc.).

The Lisa - which initially was sold with much more RAM than a Mac - had a
more sophisticated memory management scheme. Does anyone know details?
--
Philip Machanick                   [e-mail]
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa        (at University of Cape Town 4 July-7 Nov)
phone [phone]  fax [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Peter Castine)
Date: Fri, 28 Oct 1994 12:13:55 GMT
Organization: Process Control Center

In article <[e-mail]>, (Stephen M.
Webb) wrote:
> > Virtual memory became possible only with the 68020, which was not in
> > production at the time the Mac was released.

In response, in article <[e-mail]>,
[e-mail] (Philip Machanick) wrote:
> The Lisa - which initially was sold with much more RAM than a Mac - had a
> more sophisticated memory management scheme. Does anyone know details?

Lisa had a PMMU and (I'm 99% sure of this) memory protection. I'm not sure
about virtual memory (the first Lisas were diskette-based, but later
models had external hard disks).


Philip also said:
> I don't think this is sufficient reason to introduce handles. Other
> systems had things like overlays (clumsy but easier to program). I think
> the real reason for overlays was system calls and user program were
> allocating sometimes short-lived data (e.g. for menus) in the same small
> heap. With so little RAM to play with a conventional memory manager would
> have had problems coping. Things like puregeable resources help, but could
> work without handles if there is enough free RAM to run a conventional
> memory manager (with free list, coalescing adjacent blocks etc.).

Menus should never be purgeable. But windows (particularly Dialogs and
Alerts) come and go and chew up memory. Ditto for fonts.

Overlays *are* clumsy, require a lot of attention on the part of the
applications programmer (IMO, more work than the occaisional
_HLock/_HUnlock call), and are usually used for swapping sections of
program code (and, hence, don't help with memory requirements of windows,
etc.).

--
Peter Castine               | Useful approximations:
[e-mail]   |  Pi seconds is a nanocentury.
Process Control Center      |  Electricity travels a foot per nanosecond.
Technical University Berlin |  One ostrich egg will feed 24 people for brunch.

+++++++++++++++++++++++++++

>From [e-mail] (Chris Driving in the Rain Tate)
Date: Fri, 28 Oct 1994 12:54:47 GMT
Organization: DCRT, NIH, Bethesda, MD

In article <[e-mail]>, [e-mail] (Philip Machanick) writes:
>In article <[e-mail]>, [e-mail] (Stephen M.
>Webb) wrote:
>> Virtual memory became possible only with the 68020, which was not in
>> production at the time the Mac was released.  Handles were required to
>> support a pseudo-virtual memory scheme under which regions of memory
>> could be relocated during a system call if necessary, and without
>> notice, at run time.  Such a scheme does not require restartable
>> instructions.
>
>I don't think this is sufficient reason to introduce handles. Other
>systems had things like overlays (clumsy but easier to program). I think
>the real reason for overlays was system calls and user program were
>allocating sometimes short-lived data (e.g. for menus) in the same small
>heap. With so little RAM to play with a conventional memory manager would
>have had problems coping. Things like puregeable resources help, but could
>work without handles if there is enough free RAM to run a conventional
>memory manager (with free list, coalescing adjacent blocks etc.).

Overlays are only for code, most times.  The CODE segment structure of
the Mac's runtime environment is far superior, IMHO.  What people are
talking about here is using the PMMU to move stuff around in physical
memory without changing its logical addressing, transparently to the
application.

Basically, the reason the Mac doesn't do this is that the MC68000 doesn't
have any hardware memory-management; handles were a way to give the OS
*some* way of making room for new allocations in a fragmented heap.

>The Lisa - which initially was sold with much more RAM than a Mac - had a
>more sophisticated memory management scheme. Does anyone know details?

The Lisa was an amazingly advanced machine for its day.  It *did* have
hardware memory management, and preemptive multitasking.  It achieved this
through custom hardware to supplement the 68000 (which, as I said, didn't
offer any of this functionality itself).  This is part of what made the
Lisa so expensive, unfortunately; it was too much technology for the niche
it needed to occupy.

- ------------------------------------------------------------------
Christopher T{te           | "I never thought of surgery as 'editing
[e-mail]  |  a person' before...."
eWorld:  cTate             |        -- Mark Linton ([e-mail])

+++++++++++++++++++++++++++

>From "Donald T. Major" <[e-mail]>
Date: Fri, 28 Oct 1994 15:11:05 GMT
Organization: SAS Institute Inc.

Handles, and the Lisa memory management, etc., all came from the
work achieved with Smalltalk-80. Handles are a direct descendant of
the object table of Smalltalk, just implemented in a more flexible
manner. Sure, in Smalltalk object references were offsets in the
object table, and the only "real" pointers the system used were the
result of resolving such a reference, but the basic idea was there (it
may even be older than that--I honestly don't know). The really neat
part about the Smalltalk model, though, was that it allowed for a very
flexible virtual memory scheme, where disk I/O was even more of a
major system expense than it is today. LOOM and another similar scheme,
the name of which escapes me at the moment, were virtual memory systems
implemented for Smalltalk, to allow moving only the minimum amount of
data to and from disk as necessary. Implemented entirely in software,
they could make use of ridiculously small chunks of memory (since most
objects were ridiculously small) to load an object from disk, while
keeping as many current system objects loaded as possible, and cutting
back on the total amount of RAM lost to pad bytes. Since RAM in the
original Smalltalk-80 implementation couldn't exceed 2 meg, this was
a very desirable goal.

This flexibility is why handles were used in the Mac from day one (and
I believe in the Lisa, though I can't swear to it)--the original Mac
only had 128k of ram, of which only about 80k was available to
applications; even the Finder was an application which was just run
when no other applications were loaded. The virtual memory scheme was
also adapted, though only for loading stuff in, not writing data back
out (CODE resources, MDEFs, etc., are all based on this scheme). It's
true that the original reasons for handles are gone, but that doesn't
mean that their usefulness is; I personally rarely find using handles
that much of a hassle, while heap fragmentation can be very irritating,
and often means I need more RAM for my heap.

*Maybe* when we finally get virtual addressing I'll feel differently
(note, this is NOT virtual memory), but for now, I like the Handle.

+++++++++++++++++++++++++++

>From Jonathan Gary <[e-mail]>
Date: Thu, 3 Nov 1994 17:55:02 GMT
Organization: Eastman Kodak

> Message-ID: <[e-mail]>

In article <[e-mail]> Stephen M. Webb,
[e-mail]
writes:
> Virtual memory became possible only with the 68020, which was not in
> production at the time the Mac was released.

This is mostly correct, as the 68010 also supports interruptable
instructions
which allow mid-instruction page faults. With all the addressing modes of
the
68K, a single instruction can cause a large number (I think as many as
17) page
faults.

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 07 Nov 1994 10:12:50 -0700
Organization: Novell, Inc., Walnut Creek Macintosh Client Site

In article <[e-mail]>,
Jonathan Gary <[e-mail]> wrote:

> In article <[e-mail]> Stephen M. Webb,
> [e-mail] writes:
>
> > Virtual memory became possible only with the 68020, which was not in
> > production at the time the Mac was released.
>
> This is mostly correct, as the 68010 also supports interruptable
> instructions which allow mid-instruction page faults.

Not really. There were several UNIX systems which handled virtual memory
page faults on a regular old 68000 by handing control to their *second*
68000 ...

--
 Views expressed here do not necessarily reflect those of my employer.

+++++++++++++++++++++++++++

>From [e-mail] (Larry Rosenstein)
Date: Thu, 3 Nov 1994 22:11:13 GMT
Organization: Taligent, Inc.

In article <[e-mail]>,
[e-mail] (Philip Machanick) wrote:

> The Lisa - which initially was sold with much more RAM than a Mac - had a
> more sophisticated memory management scheme. Does anyone know details?

The Lisa supported segmented virtual memory and protected address spaces,
but it still used handles.  (BTW, I believe it had a custom MMU.)

The main reason was that data segments could not be automatically paged in
and out, because the 68000 CPU didn't support restarting instructions on a
fault.  (68000 machines that did support full demand paging like the early
Apollos used 2 CPUs, one of which was dedicated to loading pages from the
disk.)

The Lisa did support demand paging of code segments and automatic stack
expansion.  This was possible because there were a limited set of
instructions used to access code segments, and the OS group figured out
how to restart those instructions.

Similarly for the stack segment, the compiler generated a TST instruction
at function entry to touch the maximum stack address needed in the
function.  The OS knew how to restart that instruction as well.

Handles are useful in an environment with a fixed sized data space where
heap blocks of varying size are allocated and deallocated relatively
frequently.

--
Larry Rosenstein
Taligent, Inc.

[e-mail]

---------------------------

>From [e-mail] (G. Gavazzi)
Subject: Q: Sound Input Device
Date: 1 Nov 1994 01:36:02 GMT
Organization: University of Cambridge, England

Hi everybody,
I need some help, sorry for the naive question: I am using:

Handle rate;
SPBGetDeviceInfo(myInRefNum,siSampleRateAvailable,*rate);

to determine the available sampling rate of the sound device input.  Now
the Inside Mac VI tells that this function returns an Integer and a Handle
(list of sample rates of type Fixed).  I think then that *rate points to a
4 bytes int, the next 4 bytes Fixed being allocated for the first sample
rate and so on.  Besides the fact that I do not know what kind of type is
Fixed (fixed point? not standard C certainly) I cannot get a sensible
result out of this :(


Also my SPBRecordToFile(out_file,&myinParam,FALSE) does not fill my
out_file, I think because the sampling rate is 0.  And I cannot set the
sampling rate with SPBSetDeviceInfo() 'cause I get bad sampling rate error
(-225).  (btw: I am using the wonderful CW4 :)

Can somebody point me to some example source code (I should be able to ftp
a develop issue if necessary)?

Thank you.
Giuliano Gavazzi

+++++++++++++++++++++++++++

>From [e-mail] (Chris Burns)
Date: Tue, 01 Nov 1994 21:33:16 +1200
Organization: AucklandUniversity:ComputerScience:HMU

In article <394622$[e-mail]>, [e-mail] (G.
Gavazzi) wrote:

> to determine the available sampling rate of the sound device input.  Now
> the Inside Mac VI tells that this function returns an Integer and a Handle
> (list of sample rates of type Fixed).  I think then that *rate points to a
> 4 bytes int, the next 4 bytes Fixed being allocated for the first sample
> rate and so on.  Besides the fact that I do not know what kind of type is
> Fixed (fixed point? not standard C certainly) I cannot get a sensible
> result out of this :(

/////////////////////////////////////////////////////////////////////////
// Include appropriate header files

#include <SoundInput.h>
#include <FixMath.h>

/////////////////////////////////////////////////////////////////////////
// Set up types to access a handle to an array of Fixed

typedef Fixed RateList[];
typedef RateList **RateListHandle;

/////////////////////////////////////////////////////////////////////////
// Define a structure according to IM6 22-67 'srav'

struct{
    short           count;
    RateListHandle  rates;
}SampleRates;

/////////////////////////////////////////////////////////////////////////
// Get sound input device to fill in the "SampleRates" struct

    Err = SPBGetDeviceInfo(RefNum,siSampleRateAvailable,(Ptr)&SampleRates);
    FailOSErr(Err,"\p_SPBGetDeviceInfo[siSampleRateAvailable] FAILED");

/////////////////////////////////////////////////////////////////////////
// For example, pick the highest sampling rate from the ones returned.

long        MaxLong;
long        MaxPos;
Fixed       CurFixed;
long        CurLong;
short       i;


    if (SampleRates.count == 0)
        SampleRate = (**SampleRates.rates)[2];
    else
    {
        MaxLong = 0;
        MaxPos = 0;

        for (i = 0;i < SampleRates.count;i++)
        {
            CurFixed = (**SampleRates.rates)[i];
            if (BitTst((Ptr)&CurFixed,0))
            {
                BitClr((Ptr)&CurFixed,0);
                CurLong = 32768 + Fix2Long(CurFixed);
            }
            else
                CurLong = Fix2Long(CurFixed);

            if (CurLong >= MaxLong)
            {
                MaxLong = CurLong;
                MaxPos = i;
            }
        }
        SampleRate = (**SampleRates.rates)[MaxPos];
    }

/////////////////////////////////////////////////////////////////////////
// Set sampling rate

    Err = SPBSetDeviceInfo(RefNum,siSampleRate,(Ptr)&SampleRate);
    FailOSErr(Err,"\p_SPBGetDeviceInfo[siSampleRate] FAILED");

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]                         Async, therefore I am.
- ---------------------------------------------------------------------

---------------------------

>From Pete Gontier <[e-mail]>
Subject: QC FAQ
Date: 1 Nov 1994 08:01:21 GMT
Organization: Pete's Proxy Posting, Ink.

This is a monthly posting. Changes this month: none.
This posting is available via 'ftp':

    ftp://ftp.dnai.com/users/gurgle/QC_FAQ.txt

Poster has no affiliation with Onyx Technology. Please email
responses to addresses listed at the bottom of this text.

- --------------------- cut here -----------------------

QC(tm) FAQ 0794.2
=================

Q: So what is QC?

A: QC is a control panel/extension that adds the ability to stress test
applications for runtime, memory related errors. QC can be used during
development, during testing by inhouse and beta testers, and after the
product ships (although a little late if errors are detected) by end
users to evaluate the stability of a software package.

Q: Is there a demo available?

A: Yes. It is available from most online services as well as Internet
sites like sumex.

Q: What do I have to do to use the demo?

A: Put QC in your Control Panels folder and reboot your Mac. If the demo
has expired contact us at one of the online addresses listed above.

Q: Can I use QC to test existing applications without rebuilding them?

A: Yes. QC was designed to test applications without requiring any
modifications to the code. The release version of QC includes an
optional application programming interface (QCAPI) that programmers can
use to control QC testing directly from their code.

Q: How does QC report errors it finds?

A: QC reports detected errors through the use of a low level debugger.
QC uses the _DebugStr trap to cause a user break into your favorite
debugger. QC is fully compatible with MacsBug, TMON, TMON PRO, The
Debugger, SourceBug, SADE, THINK C, CodeWarrior, MPW, etc. If you turn
off debug breaks in the list of options, QC will emit a short
distinctive beep when errors are detected.

Q: Does QC work on a Power Macintosh?

A: Yes. However, two incompatible tests are disabled if you are using
the Modern Memory Manager. Those tests are 'Block Bounds Checking' and
'Invalidate Free Memory'. The next release of QC will be a native
PowerPC application and will be available as a free upgrade to existing
users.

Q: How does QC compare with tools such as Even Better Bus Error and the
debugging version of the Modern Memory Manager?

A: EBBE is a free utility but one downfall it has is that it's either
installed or it isn't. You either get bus errors potentially caused in
all running apps or you get nothing. With QC, you can control when
testing is active and what apps might potentially crash with a bus
error. Everything is unaffected. Although early development versions
were available, we are not aware of any debugging version of the Modern
Memory Manager being made available by Apple at this time. Early
versions of MMM were much slower than QC in comprobable tests and the
MMM does not offer as many tests as QC does. There is also no easy to
use UI to activate/deactivate MMM testing on an application heap.

Q: What are the advantages to using QC?

A: QC offers tests that are not available anywhere else and it performs
many tests much faster than other testing tools. All QC's tests are
integrated into a single INIT/cdev combination. A Macintosh interface
makes QC usable right out of the box. QC's API can be used to fine tune
testing to specific areas of code (new code or suspect code, for
example). QC reports more information when an error is found.

Q: What do I get when I purchase QC?

A: The following is contained on the release disk. A fully licensed copy
of QC for single machine use and complete documentation. The QC
Application Programming Interface (QCAPI) libraries and interfaces for
those who want to control QC testing directly from their code. Full
source code to an application called BadAPPL that illustrates what QC
detects as well as how to use the QCAPI. The disk also contains some
assorted free utilities.

Q: How can I obtain QC?

A: Pricing is $99.95 for a single copy, $400 for a five pack, and $700
for a ten pack. Please add $5 shipping and handling to each order.
Credit card orders are accepted. You can contact Onyx via the email
addresses listed above or by calling 813.795.7801 or faxing
813.795.5901. You can also send regular mail to:

Onyx Technology
7811 27 Ave W
Bradenton, FL 34209

Our email addresses are:

America Online:  OnyxTech
Internet:        [e-mail]
AppleLink:       D2238
CompuServe:      70550,1377

QC is a trademark of Onyx Technology
Copyright (c) 1994 Onyx Technology

---------------------------

>From [e-mail] (Cazelais Gilles)
Subject: ResEdit 2.1.3, is it good this time?
Date: Wed, 26 Oct 1994 07:26:07 GMT
Organization: Universite de Montreal


Hello folks,
              I just want to know if the recent version of ResEdit
(2.1.3) is a good version without known bugs, like the nasty one in
version 2.1.2.  Is anybody having some troubles with 2.1.3?  Any
problems with it?

In brief, can I trust it??  I really want to be sure before using it...

Thanks a lot,

                Martin.

+++++++++++++++++++++++++++

>From [e-mail] (Aatrix)
Date: 26 Oct 1994 08:20:01 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail]
(Cazelais Gilles) writes:

>               I just want to know if the recent version of ResEdit
> (2.1.3) is a good version without known bugs, like the nasty one in
> version 2.1.2.  Is anybody having some troubles with 2.1.3?  Any
problems
> with it?

Uh, which nasty bug?  The one that tanked a file if you copied a resource
over another that was smaller has been fixed.  Don't know about some of
the others (CNTLs in DLOGs don't display on a Quadra, for one thing).

a.d. jensen,
Aatrix Software, Inc.
[e-mail]
  "Forty below keeps out the riff-raff." - North Dakota State Motto


+++++++++++++++++++++++++++

>From [e-mail] (Alain Aslag Roy)
Date: Wed, 26 Oct 1994 12:57:12 GMT
Organization: Department of Computer Science, University of Chicago

In article <[e-mail]> [e-mail] (Cazelais Gilles) writes:
>
>Hello folks,
>              I just want to know if the recent version of ResEdit
>(2.1.3) is a good version without known bugs, like the nasty one in
>version 2.1.2.  Is anybody having some troubles with 2.1.3?  Any
>problems with it?

I've had no problems with Resedit 2.1.3, and I use it a fair amount. I
did have problems with 2.1.2, so I guess they really did fix those
heinous crashes.

-alain

+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: Wed, 26 Oct 1994 11:44:23 -0400
Organization: The Pitt, Chemistry

In article <[e-mail]>, [e-mail]
(Cazelais Gilles) wrote:


>               I just want to know if the recent version of ResEdit
> (2.1.3) is a good version without known bugs, like the nasty one in
> version 2.1.2.  Is anybody having some troubles with 2.1.3?  Any
> problems with it?
>
> In brief, can I trust it??  I really want to be sure before using it...

   What the X-files slogan "Trust no one, backup frequently?" :-)

   I've been using 2.1.3 for a while now, and had none of the
     corruption problems that I did with 2.1.2.  I seem to remember
     a post when 2.1.3 was released claiming all reported bugs were
     dealt with, and that *seems* to be the case.


 Internet: [e-mail]            _/   _/  _/  _/_/_/   _/   _/
   eWorld: nick                     _/_/ _/  _/  _/   _/  _/_/_/
      CIS: 71232,766               _/ _/_/  _/  _/       _/ _/
     http://www.pitt.edu/~nick/   _/   _/  _/   _/_/_/  _/   _/


+++++++++++++++++++++++++++

>From [e-mail] (Ross Brown)
Date: Wed, 26 Oct 1994 12:40:49 -0400
Organization: Bell-Northern Research

In article <[e-mail]>, [e-mail]
(Cazelais Gilles) wrote:

> Hello folks,
>               I just want to know if the recent version of ResEdit
> (2.1.3) is a good version without known bugs, like the nasty one in
> version 2.1.2.  Is anybody having some troubles with 2.1.3?  Any
> problems with it?

The nasty 2.1.2 bugs are indeed gone.  No more file corruption.  But...

Try this on a Power Mac.  It doesn't seem to happen on 68K Macs - odd,
since ResEdit runs in full emulation on PPC.  I find that this happens
even with all extensions (and Modern Memory Manager) off.

Copy some resources into the Clipboard.  In ResEdit, open a file whose
resource fork has no resources of the types represented in the Clipboard,
then paste them in.  Close the file, and click "No" when asked if you want
to save the file.  Open the file, and you'll find that the resources
*were* added to the file, against your instructions.

I sincerely hope that this bug is not traceable to the emulator.

--
Ross Brown
Macintosh/UNIX Systems Integration
Bell-Northern Research Ltd.
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Sean Crist)
Date: 26 Oct 1994 20:14:31 GMT
Organization: University of Pennsylvania, Linguistics Department

In article <[e-mail]>,
Cazelais Gilles <[e-mail]> wrote:
>
>Hello folks,
>              I just want to know if the recent version of ResEdit
>(2.1.3) is a good version without known bugs, like the nasty one in
>version 2.1.2.  Is anybody having some troubles with 2.1.3?  Any
>problems with it?
>
>In brief, can I trust it??  I really want to be sure before using it...

There's at least one bug I've come across.  Unfortunately I didn't make
notes of the specific circumstances, but I remember that I was able to
replicate it.  It was something in the DITL editor; I think it had to do
with resizing CNTL items or something like that.

  \/ __ __    _\_     --Kurisuto  ([e-mail])
 ---  |  |    \ /
  _| ,| ,|   -----    For a free copy of the Bill of Rights, finger
  _| ,| ,|    [_]     this account.
   |  |  |    [_]


+++++++++++++++++++++++++++

>From [e-mail] (Cazelais Gilles)
Date: Wed, 26 Oct 1994 22:51:30 GMT
Organization: Universite de Montreal

In article <[e-mail]> [e-mail] (Alain Aslag Roy) writes:
>In article <[e-mail]> [e-mail] (Cazelais Gilles) writes:
>>
>>Hello folks,
>>              I just want to know if the recent version of ResEdit
>>(2.1.3) is a good version without known bugs, like the nasty one in
>>version 2.1.2.  Is anybody having some troubles with 2.1.3?  Any
>>problems with it?
>
>I've had no problems with Resedit 2.1.3, and I use it a fair amount. I
>did have problems with 2.1.2, so I guess they really did fix those
>heinous crashes.
>
>-alain


So, do you think it really worth to upgrade it from 2.1.1?




+++++++++++++++++++++++++++

>From [e-mail] (Simon Fraser)
Date: Sat, 29 Oct 94 15:56:35 GMT
Organization: Centre for Population Biology

In article <38mdb7$[e-mail]> Sean Crist,
[e-mail] writes:
>There's at least one bug I've come across.  Unfortunately I didn't make
>notes of the specific circumstances, but I remember that I was able to
>replicate it.  It was something in the DITL editor; I think it had to do
>with resizing CNTL items or something like that.

Yes, I've had problems here. Create a new CNTL resource, open a
DLOG, make a new CNTL item, then double-click to edit it. Just
as you finish typing the ID of your new CNTL, ResEdit crashes.
I've found that saving the file _before_ opening the DLOG helps.

I've also found that sometimes editing resources with templates
fails to set the 'window dirty' flag (or whatever tells ResEdit
that you've made changes), so ResEdit fails to save changes
to the resource.

I'm sure there are one or two other things that I've forgotten....

Simon
__________________________________________________________________________
Simon Fraser                            NERC Centre for Population Biology
[e-mail]                         Imperial College at Silwood Park
                                             Ascot, Berkshire, SL5 7PY. UK

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Mon, 31 Oct 1994 12:14:37 +0800
Organization: NCRPDA, Curtin University

ResEdit 2.1.3 is quite useable, but it still has bugs.  One that gets me a
lot is thast it locks up when you open the DITL editor if there is strange
things in the clipboard.  This is on a 6100, System 7.5 - it reliably
locks up every time if I copy stuff out of SimpleText and then open a
dialog window for editing in ResEdit.  So I just copy something in ResEdit
before editing dialogs.
   Peter.
--
Peter N Lewis <[e-mail]> - Macintosh TCP fingerpainter
FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or
amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/

+++++++++++++++++++++++++++

>From [e-mail] (Jason Grossman)
Date: Mon, 31 Oct 1994 15:03:50 +0000
Organization: University of Cambridge

Peter N Lewis wrote:

> ResEdit 2.1.3 is quite useable, but it still has bugs.  One that gets me a
> lot is thast it locks up when you open the DITL editor if there is strange
> things in the clipboard.  This is on a 6100, System 7.5 - it reliably
> locks up every time if I copy stuff out of SimpleText and then open a
> dialog window for editing in ResEdit.  So I just copy something in ResEdit
> before editing dialogs.
>    Peter.

Ah! It does this to me, too (7100, 7.1), but I'd never realised what the
conditions were, so I didn't know the work-around of copying something
before opening a DITL. I've been using the alternative work-around of
opening the DITL, getting the crash, pressing the emergency reboot button,
waiting for the machine to restart, and then opening the DITL again.

Jason

+++++++++++++++++++++++++++

>From [e-mail] (alyx)
Date: Thu, 3 Nov 1994 03:46:24 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] ( nick.c ) wrote:

>      [...]  I seem to remember
>      a post when 2.1.3 was released claiming all reported bugs were
>      dealt with, and that *seems* to be the case.

ah, memories.  anyone else remember the beloved 4D Tools dialog box:

  "No problems found.  Everything *seems* OK."

quite a nasty sense of humor there...

alex.

---------------------------

>From red.riders
Subject: Shareware, VISA Merchant Accounts, and YOU!
Date: Thu, 03 Nov 1994 00:27:00 -0500
Organization: DSC/Voicenet - BBS/Unix Shells/SLIP/NEWS - [phone]

Hey homeys, here's some info I had laying around. No more bitching
about lost shareware dollars, OK?


            Increase Your Business by Taking Mastercard and Visa


Credit card industry experts report that offering customers the ability to pay
with Visa or Mastercard will increase a company's business between 10%
and 50%. Whether the increase is closer to 10% or 50% depends on the type
of business and its particular clientele. Yet there can few tasks more
difficult for a home-based business than obtaining a merchant account. This
is because of discrimination against home-based as well as other types of
businesses by most banks. Nevertheless, home-based businesses do manage
to be able to offer their customers the ability to use their charge cards.
There are four basic avenues for securing a merchant account.

I. Financial Institutions
A. Banks

Even though banks as a general rule are not granting home
businesses merchant accounts for taking Visa & Mastercard, do try
your own bank, particularly since they know you as a customer. If
your bank denies you a merchant account, try small independent
banks, particularly ones that have their merchant accounts processed
by an out-of-state bank instead of doing it themselves or using a
larger local bank. Banks in smaller communities are more apt to work with
home-based businesses.

B. Saving & Loans, Thrifts and Credit Unions

Most people think of banks as THE only financial institutions
granting merchant accounts to businesses. However, savings & Loans, thrifts
and even credit unions are increasingly offering merchant accounts. You
may find these institutions more willing to work with you.
Remember that banks, in the words of Larry Schwartz and Pearl
Sax founders of the National Association of Credit Car Merchants (217 N.
Seacrest Boulevard, Box 400, Boynton Beach, Florida 33425; (407)
737-7500), "need
reassurance that handling your business will both safe and profitable." It
almost goes
without saying that your presentation of your business, your financial
ability and
yourself must make your banker feel absolute confidence in you.

II. Business Organizations
A. Trade Associations

Trade associations sometimes provide access to Visa and Mastercard
accounts as a member service. Examples of organizations that may be
helpful are the Retail Merchants Association and Direct Marketing
Association and others specifically related to your particular industry.
To find trade associations in your field, use Gale's Encyclopedia of
Associations, available at the reference desk in most libraries.

B. Local Business Organizations.

Chambers of Commerce and local merchant associations sometimes help
their members secure merchant accounts through a bank affiliated with the
Chamber or the association. These can be the least costly merchant accounts
with discounts as low as 2% to 3% on relatively small volumes.
III. Independent Selling Organizations

Perhaps the most likely way to get a merchant account is to work through a
bank agent or independent sales organization (ISO), which is a company
that acts as an intermediary between small businesses and banks. You will
undoubtedly pay more using an ISO because these companies derive their
income from fees and surcharges added to what you would normally pay if were
able to deal directly with a bank.

You may be quoted these fees and charges when going through an ISO:

 o Application fees ranging between $95 to $325. These may or may not be
   refundable. Usually they are not, but find out under what circumstances
   all or part of the fee may be refundable.

  o Point of sale terminal lease or purchase. ISO's typically charge from
    $425 to $1700 for a terminal if purchased through a bank would cost
    about $300. Leasing typically runs between $18 and $80 a month. Some
    ISO's are offering software that can be used in place of a sales terminal,
    priced as low as $150.

  o Service fees from 3.5% to 7% compared to 2% to 5% from a bank, though
one ISO
    is quoting fees of 1.99%. This ISO has other charges that tend to make
up fo the lower
    service fee.

  o Per transaction charge of $.20 to $.25

  o Monthly statement fee of $5.00 to $10.00

  o Minimum monthly fee

Advice about dealing with ISO's. Fees vary considerably among ISO's, so it
pays to be a
comparison shopper. Read the contract carefully for hidden charges and
requirements. You
may also be required to use a check verification service provided by the
ISO for an
additional fee. One final warning. The salespeople for ISO's may be so eager
to sign you up that they may inaccurately fill out your applications about
items that
would not be approved if filled in accurately. The problem is that if a
falsehood is
detected later by the bank, your merchant account may be terminated and your
name placed on a terminated merchant list that bars you from getting another
merchant account in the future. Subject that are sometimes filled in include
whether the salesperson has personally inspected your premises and the
percentage mail order and telephone constitute of your sales. Be sure to
check your filled in application for accuracy.

Following are independent selling organizations listed in alphabetical order
that have told us or have been reported by members of the forum to accept
home businesses for merchant accounts (Asterisked entries are posted in this
file for the first time):

Bancard, Inc.
    1233 Sherman Drive
    Longmont, CO 80501
    303/530-0264
    800/666-7575

Requires two years in business at the same address.

Data Capture Systems
    231 Quincy Street
    Rapid City, SD 57701
    605/341-6461

Comes to your home for an on-site interview and charges $25 to send
an application plus a $300 application fee.

Electronic Bankcard Systems
    2554 Lincoln Blvd., Suite 1088
    Marina Del Rey, CA 90291
    213/827-5772

No mail order, telemarketing or spa sales

Gold Coast Bankcard Center
     Ft. Lauderdale , FL
     305-492-0303

Affiliated with American Bankcard Center 800-777-VISA

Harbridge Merchant Services
     681 Andersen Drive, 4th Floor
     Building Six
     Pittsburgh, PA 15220
     [phone]

Under prior ownership, this company was called Peachtree. As Peachtree, it
was the subject of many complaints, but since the change in ownership,
the reports are more positive.

Teleflora Creditline
     12233 West Olympic Boulevard
     Los Angeles CA 90064
     800-325-4849 or 310/526-5233.

Deals primarily with bulletin boards.

US Merchant Services
     775 Park Avenue
     Huntington, NY 11743.
     516 427-9700
     Fax [phone]
     Thomas A. McGuire

IV. Options Other Than Visa and Mastercard

What about American Express and Discover? More people are likely to
have a Visa or Mastercard. In early 1992 these were the market shares for
each of the
principal cards: Visa - 46%; Mastercard - 26%; Am Express - 20%; Discover - 7%.

But American Express is easier to get than Visa and Mastercard. To contact
American Express, call 800/528-5200. Discover is reportedly as difficult to
get as Visa and Mastercard; however, the number to call is 800/347-6673.

+++++++++++++++++++++++++++

>From [e-mail] (Will Iverson)
Date: Thu, 03 Nov 1994 00:27:44 -0800
Organization: University of California, Davis

In article <[e-mail]>,
red.riders wrote:

> Hey homeys, here's some info I had laying around. No more bitching
> about lost shareware dollars, OK?
>
>
>             Increase Your Business by Taking Mastercard and Visa
>
<snip>

Thanks tremendously for the info!  Very interesting & informative!

-Will

+++++++++++++++++++++++++++

>From [e-mail] (David Bayly)
Date: Thu, 03 Nov 1994 10:14:50 -0500
Organization: Chez moi

In article <[e-mail]>,
[e-mail] (Will Iverson) wrote:

> In article <[e-mail]>,
> red.riders wrote:
>
> > Hey homeys, here's some info I had laying around. No more bitching
> > about lost shareware dollars, OK?
> >             Increase Your Business by Taking Mastercard and Visa
> >
> <snip>
>
> Thanks tremendously for the info!  Very interesting & informative!
>
> -Will

Theres also, netcash, which I am in the process of learning about. The way
to do that is to send mail to [e-mail]. They have merchant
accounts, Peter Lewis for one uses them.
--
- David Bayly       [e-mail]
"If you keep your mind sufficiently open, people will throw a lot of rubbish into it." -William A. Orton

+++++++++++++++++++++++++++

>From [e-mail] (Sean Crist)
Date: 3 Nov 1994 21:41:46 GMT
Organization: University of Pennsylvania, Linguistics Department

One thing to be careful of if you're arranging this: the bank may charge
you a minimum monthly fee for this service (something like $5 or $10 a
month).  I once arranged VISA/MasterCard service of this sort for a small
charitable organization; I can't remember all the details, but I remember
that it ended up being enough of a money leech that we decided that it
wasn't worth it to continue the arrangement.

  \/ __ __    _\_     --Kurisuto  ([e-mail])
 ---  |  |    \ /
  _| ,| ,|   -----    For a free copy of the Bill of Rights, finger
  _| ,| ,|    [_]     this account.
   |  |  |    [_]

---------------------------

>From [e-mail] (John Nagle)
Subject: Smalltalk implementations for Mac - update needed
Date: Fri, 28 Oct 1994 06:26:27 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

    I've been away from Smalltalk on the Mac for a while, and I need
to get up to date.  I'd appreciate answers to the following questions.

    1.  I know about ParcPlace and Digitalk.  Any other vendors?
    (Somebody else was in Real Soon Now status, as I recall.)

    2.    Did Digitalk ever do much with the Mac implementation, like
    provide a compiler or a reasonable way to generate a standalone app?

    3.  I need something that can respond to Table Suite AppleEvents.
    (That is, I will be writing a program that responds, but I need
    a Smalltalk with AE support.)  Suggestions?

Thanks.

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Patrick Podenski)
Date: Sat, 29 Oct 1994 18:39:46 -0700
Organization: Northwest Nexus

In article <[e-mail]>, [e-mail] (John Nagle) wrote:

>     I've been away from Smalltalk on the Mac for a while, and I need
> to get up to date.  I'd appreciate answers to the following questions.
>
>     1.  I know about ParcPlace and Digitalk.  Any other vendors?
>         (Somebody else was in Real Soon Now status, as I recall.)
>
>     2.  Did Digitalk ever do much with the Mac implementation, like
>         provide a compiler or a reasonable way to generate a standalone app?

A new version was put out a while ago (V 2 ?), but I haven't seen it.
>
>     3.  I need something that can respond to Table Suite AppleEvents.
>         (That is, I will be writing a program that responds, but I need
>         a Smalltalk with AE support.)  Suggestions?

There is a new Smalltalk from Quasar Knowledge Systems for the Mac that is
supposed to be nice. It apparently caters to Mac specific things like you
mentioned in 3.

--
- ----------------------------------------------
Pat Podenski         |  my opinions are my own,
[e-mail] |  as are yours yours!
- ----------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Sat, 29 Oct 1994 20:49:05 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (John Nagle) wrote:

>     I've been away from Smalltalk on the Mac for a while, and I need
> to get up to date.  I'd appreciate answers to the following questions.
>
>     1.  I know about ParcPlace and Digitalk.  Any other vendors?
>         (Somebody else was in Real Soon Now status, as I recall.)

QKS (Quasar Knowledge Systems) SmalltalkAgents.  I bought that on nearly
the last day of their User group special (ended Sep 30).  I like it a
lot.  It provides pretty good coverage of special Mac things, while at the
same time being highly cross-platform in nature (doesn't matter to me (I
don't have a cross platform, only a contented Mac), does matter to some
others).  I'm still in the learning stage, but I like "STA" a lot.

>     2.  Did Digitalk ever do much with the Mac implementation, like
>         provide a compiler or a reasonable way to generate a standalone app?

They finally did...they still don't seem terribly interested in the Mac,
however.  My Smalltalk V/Mac is back on the shelf.

>     3.  I need something that can respond to Table Suite AppleEvents.
>         (That is, I will be writing a program that responds, but I need
>         a Smalltalk with AE support.)  Suggestions?

I *think* you could arrange this either either Smalltalk V/Mac or
SmalltalkAgents.  I think it would be less work with SmalltalkAgents.

--John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   Sorry...clever signatures require cleverness, not found here.
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Alun ap Rhisiart)
Date: 30 Oct 94 17:02:30 GMT
Organization: Oxford University VAX 6620

In article <[e-mail]>, [e-mail] (John Nagle) writes:
>     I've been away from Smalltalk on the Mac for a while, and I need
> to get up to date.  I'd appreciate answers to the following questions.
>
>     1.  I know about ParcPlace and Digitalk.  Any other vendors?
>     (Somebody else was in Real Soon Now status, as I recall.)
Those two plus QKS SmalltalkAgents. I don't think Smalltalk/X is on the Mac yet
(and neither is IBM's VisualAge, as you might have guessed).
>
>     2.    Did Digitalk ever do much with the Mac implementation, like
>     provide a compiler or a reasonable way to generate a standalone app?
>
Not really. You had v1.2 didn't you, John? When the released v2 I was looking
forward to something better than that old cloner, but no, it was exactly the
same.  They did do a lot to v2.0 (like system 7 support - including AE - and an
even-driven interface, block-based exceptions, stuff like that). Unfortunately,
the changes meant that the old tools, like Widgets (a al windowbuilder),
Profile/V, and so on, no longer worked. We are _still waiting_ for an update
for widgets to give us a GUI builder! Compatibility with other platforms is
said to be 'improved', but evidently not much or windowbuilder would have been
ported a year ago.  It is also no faster, by the way, and Digitalk are not more
responsive (except, I gather, through Compu$erve - although they are on this
group more often now, which is something).
>     3.  I need something that can respond to Table Suite AppleEvents.
>     (That is, I will be writing a program that responds, but I need
>     a Smalltalk with AE support.)  Suggestions?
>
STA is the way to go for this kind of stuff (and a lot else). The main
criticisms of it at the moment would be: on Mac only (but other platforms on
the way); no equivalent of Envy for version control and config management (but
home grown solution due in v2); changes management is pretty poor (less
reliable and convenient than even St/Vs change log), but again is being worked
on.
Main strengths are: speed; very easy access to C (especially), pascal, fortran,
etc functions; saving objects to file or sending over network is very nicely
done, and *tons* faster than the V solution); multithreaded; very easy and
quick way to make standalones. My St/V is on the shelf too. The problem is that
after using STA for a while you forget how far beyond the others it has gone,
and it becomes easy to under-sell it.
> Thanks.
>
>                     John Nagle
--
 Alun ap Rhisiart
 Animal Behaviour Research Group
 Oxford University
 [e-mail]
(also not a paid endorsement. Not that I object to being paid, you understand!)

+++++++++++++++++++++++++++

>From [e-mail] (Geoff Burian)
Date: 30 Oct 1994 15:01:47 -0800
Organization: Island Internet Inc - [phone]

In article <[e-mail]>, John Nagle <[e-mail]> wrote:
>    I've been away from Smalltalk on the Mac for a while, and I need
>to get up to date.  I'd appreciate answers to the following questions.
>
>    1.  I know about ParcPlace and Digitalk.  Any other vendors?
>    (Somebody else was in Real Soon Now status, as I recall.)

Check out SmalltalkAgents from Quasar Knowledge Systems.  The info
they sent me was very impressive.  There's a good article in the
April '94 edition of MacTech.  SmalltalkAgents is a superset of standard
Smalltalk, but it seems to have good access to Toolbox calls and
external (i.e., C, Pascal) code routines.

QKS - 1-800-296-1339, [e-mail]

Geof Burian
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ken Iisaka)
Date: Wed, 2 Nov 1994 23:00:26 GMT
Organization: Or Lack Thereof

In article <3918ks$[e-mail]>, [e-mail] (Geoff Burian) writes:
|> In article <[e-mail]>, John Nagle <[e-mail]> wrote:
|> >    I've been away from Smalltalk on the Mac for a while, and I need
|> >to get up to date.  I'd appreciate answers to the following questions.
|> >
|> >    1.  I know about ParcPlace and Digitalk.  Any other vendors?
|> >    (Somebody else was in Real Soon Now status, as I recall.)
|>
|> Check out SmalltalkAgents from Quasar Knowledge Systems.  The info
|> they sent me was very impressive.  There's a good article in the
|> April '94 edition of MacTech.  SmalltalkAgents is a superset of standard
                                                                   ^^^^^^^^
|> Smalltalk, but it seems to have good access to Toolbox calls and

What standard Smalltalk?  The ANSI ST?  PPS?  Digitalk?  There is no
standard that I know of that has been implemented.

--
|  ###    ###  |  ###   ###   ###  |  ###    ###  |  ###   ###   ###  |
|  ###    ###  |  ###   ###   ###  |  ###    ###  |  ###   ###   ###  |
|  ###    ###  |  ###   ###   ###  |  ###    ###  |  ###   ###   ###  |
|  ###    ###  |  ###   ###   ###  |  ###    ###  |  ###   ###   ###  |
|    |    |    |    |    |    |    |    |    |    |    |    |    |    |
|  Ken Iisaka  |  ([e-mail])  |  Morgan Stanley & Co. Inc   |
|  1 Pierrepont Plz, Brooklyn, NY 11201 |   All disclaimers apply.    |
|____|____|____|____|____|____|____|____|____|____|____|____|____|____|___
"Smalltalk Goes Object Oriented" - INFORMATIONWEEK, August 8, 1994, pg. 58

---------------------------

>From [e-mail] (Geoff Pointer)
Subject: What is MIDI Manager etc (reply)
Date: 1 Nov 1994 00:26:05 GMT
Organization: PatchUp

There's nothing wrong with writing your own MIDI driver unless
you don't have to (for kicks??). The whole point of an *idea*
like MIDI Manager is to provide programmers with a consistent
interface to work with that fits in with the multiprogramming
environment. The problem seems to be that for obscure business
reasons Apple has remained light on the provision and support
of MIDI facilities. Having a MIDI Manager is just like having
a File Manager or a Dialog Manager, ie, built in support.
   Unfortunately few *big* software companies are behind its
use because its been a long time coming of age and hasn't yet.
I personally would rather not have to write my own MIDI Driver
so I intend to pursue development with the MIDI manager. The
problem with music programs in a multiprogramming environment
is the use of the serial port, if you have several MIDI programs
running at once for different purposes they argue about who's
going to get the port and you often end up having to reboot.
To avoid this you use them independently which is anathema
to modern operating systems.
   The beauty of the MIDI Manager is the way it arbitrates the
use of the serial port. Now, someone here mentioned that there
are programs that let you do both - use the port directly or use
it via the MIDI Manager. Cubase is supposedly one of these -
HAH!!, as soon as you play back a piece in Cubase, via MM, any
program that uses MM solely gets nowhere. You have to open
PatchBay and turn off the port and turn it back on again every
time.
   I am still having difficulty with discovering which way to
go from this point of view as I believe the idea of being able
to have several MIDI tools open at once working in harmony is
one of the most important aspects of MIDI programming today.
Phew, there, I said it.

- --------- Cheers - Geoff %^> ----------

What???..... No signature!!??.... OK, I give in:

"I'm not afraid of dying. ...
   I just don't want to be there when it happens."  Woody Allen.

- ---------------------------------------


+++++++++++++++++++++++++++

>From [e-mail] (Christian Fowler)
Date: 2 Nov 1994 17:57:19 GMT
Organization: ACM Student Machine


You can get the OMS (open Midi System) Development kit from Opcode for
about $15.00. Several big name apps use it like Vision/StudiVision/Galaxy
(of course) as well as Deck, SampleCell II Editor, and maybe the newest
Cubase, but I'm not sure on that one. Anyway, OMS is very nice.

--
  +-+
+-+|+-+ Christian Fowler | shape
+-+|+-+ [e-mail] | FACTOR moMeNt
  +-+



---------------------------

End of C.S.M.P. Digest
**********************